Arrangement and a method relating to performance management by distributed processing

ABSTRACT

The present invention relates to an arrangement for performance management in a communication network comprising a managing system and a number of managed systems. The arrangement comprises collecting means for collecting traffic measurement data and primary processing means for primary processing of measurement data. Said primary processing means are adapted to be distributed and comprise first primary processing means provided in the managing system and a number of second primary processing means provided in a number of managed systems. The arrangement also comprises processing control means for controlling at least allocation of primary processing of measurement data to a first or to a second primary processing means.

TECHNICAL FIELD

The present invention relates to an arrangement and a method forperformance management in a communication network comprising a managingsystem and managed systems and which are based on collection of trafficmeasurement data or statistics.

BACKGROUND

Performance and operation of communication networks and particularlytelecommunication networks have to be carefully monitored and studied inorder to assure satisfactory functioning of the networks. Vital for theperformance and operation of modern communication networks is thecollection of traffic measurements. Traffic measurements are used tomonitor network performance, to ensure that traffic load is distributedin a desired way in the network. Performance management with trafficmeasurements can also be used for traffic dimensioning, to ensureprovisioning of a desired service quality and contracts, for exampleservice level agreements, and it can also serve as a basis for chargecalculations, allocation of resources etc.

Traffic measurements can be of many different kinds. It may depend onthe resource or service that is to be measured and different parameterscan be measured. Moreover the granularity of the object being monitoredmay differ considerably from one managed system to another, for examplefrom network element (NE) to all the devices within the NE etc. Entitiesor objects that are measured may be static, such as for example a switchport, or they may be dynamic, such as for example a communicationsession, e.g. an RTP (Real Time Transport Protocol) session.

Measurement data also has to be handled or processed somewhere. In knownsystems this is done in a managing system managing a number of managedsystems or network elements. Measurement data then has to be transferredfrom the location where the measurements were carried out, for examplefrom an NE, to the managing system. It is known to transfer measurementdata synchronously, i.e. it may be polled by a management system but itmay also be transmitted asynchronously from an NE. Measurements may betransmitted via messages or collectively as a file. The most predominantmode of measurement data transfer in telecommunication networks is viafile transfer from a network element to a managing system, for examplean OSS (Operation Support System). For third generation mobile networks,it is mandated that measurement data is transferred via file transferfrom an NE to an OSS, cf. for example 3GPP TS 32.431 “TelecommunicationManagement; Performance Measurement Collection Integration ReferencePoint (IRP); Requirements” and 3GPP TS 32.104 V4.0.0 “TelecommunicationManagement; 3G Performance Management (PM), (Release 4)”. It is alsoknown to record different forms of measurements, counters may be used orthe occurrence of certain events may be recorded. Very often thecollected raw measurement data from the network has to be handled byprimary processing means or be pre-processed in the OSS in order toderive higher level counts or abstractions to provide meaningful data.Such pre-processed measurements are called aggregated measurements andthey are formed by combining basic performance management counts in acalculation to form a more complex performance count.

One example of such a measurement in a GSM network is “% Frame ErasureRate”. This measurement indicates what portion (i.e. percentage) of thetotal dropped calls in an NE are due to frame erasure conditions. It iscalculated by inspecting protocol events that occur during theprocessing of calls by the NE. It is defined as

$100*\frac{\mspace{11mu}\begin{matrix}{{Number}\mspace{14mu}{{of}\mspace{14mu}}^{``}{Call}\mspace{14mu}{release}\mspace{14mu}{events}\mspace{14mu}{with}} \\{{{urgency}\mspace{14mu}{conditions}} = {9\mspace{14mu}{to}\mspace{14mu} 11^{''}}}\end{matrix}\;}{{Number}{\mspace{11mu}\;}{of}\mspace{14mu}{all}{\mspace{11mu}\;}{Call}\mspace{14mu}{release}\mspace{14mu}{events}}$

Aggregated measurements are of different complexity depending on thecomplexity of the underlying counters. It should be clear that a counter“Number of CS Call release events” is simpler than a counter “Number ofCS Call Release events with urgency condition=9-11”, since the latterinvolves examination of the protocol event parameters and the formerdoes not. Some aggregation counters are quite complex and involve theoccurrence of a number of conditions in one or more events. To derivesuch counters, examination of a number of event parameters is requiredand this in turn necessitates the collection of all data related tothese events and the transfer of this data to the OSS from the NE.

It should be clear that there are many applications consuming trafficmeasurements and the time frame of response of these applications canrange from minutes to months. Many OSS applications are used for networkand service optimization on timescales of tens of minutes. Datacollection periods are typically 15 minutes and in some cases 5 minutes.

However, it is obvious that with the continuously growing sizes as wellas complexity of networks a lot of problems are produced, amongst otherthings as far as performance management is concerned. For severalreasons therefore, e.g. due to the response times, size and complexityof real-time network management applications, much more and morefrequent data has to be collected. Another reason is that managedsystems or network elements tend to become smaller than before and alsomore than before. For example, 3^(rd) generation mobile access networksare expected to reach or exceed 15000 network elements in the short tomedium term. This means that an enormous amount of data is needed toprovide an overall picture of network performance, and data has to befetched from most or all network elements in the network. In additionthereto modern networks are diverse in nature. The range of services isgreater, network architectures have more layers and there is a greatervariety of network nodes. This means that more and different types ofmeasurements are needed and hence also for that reason more data needsto be collected.

Thus enormous amount of data, of many different types, has to becollected often in real time and moreover all this data has to betransferred to the management system, which means that there will be ahigh amount of data transfer merely for performance management purposes.Thus, capacity limitations can be produced in the communications networkbetween the respective network elements and the OSS. This is becoming acritical issue, as an example a BSC with 7000 Erlang traffic and 70%GPRS traffic subscribers may have an average data transfer rate of 1.2Mbps between the NE and OSS. In addition thereto capacity problems maybe produced in the OSS due to the amount of information that has to beparsed, pre-processed and stored in very short times. There is also aneed to produce reports in near real time which places an even greaterload on processing and storage resources.

U.S. Pat. No. 5,687,223 for example defines an architecture and a methodof selecting data from call data records using rule sets. Rules are usedto configure the data fields to be selected for particular services fromamongst the complete set of data fields. This is based on a so calledgeneralized statistics engine which essentially is an adjunct processorfor handling performance statistics. This solution is however not soefficient, simple and flexible and it will also easily involve capacitylimitations. The amounts of data that need to be transferred will alsobe far too large.

SUMMARY

It is therefore an object of the present invention to suggest anarrangement for performance management which is efficient and whichenables management of large amounts of data. It is particularly anobject of the invention to provide an arrangement for performancemanagement which is capable of frequent collection of data and whichfunctions irrespectively of the degree of complexity of networks, i.e.which also is able to handle complex networks with a large number ofsmall network elements.

It is also an object to provide an arrangement for performancemanagement well capable of real-time management and which keeps down theamount of transmission resources needed for performance management.

It is also an object to provide a performance management solution forhigh diversity networks offering many different kinds of services etc.

Particularly it is an object of the invention to provide a managing anda managed system respectively supporting performance management andthrough which one or more of the above mentioned objects can beachieved, as well as a method through which one or more of the abovementioned objects can be achieved.

In order to meet one or more of the above mentioned objects, the presentinvention suggests an arrangement for performance management to be usedin a communication network with one or more managing systems, eachmanaging a number of managed systems. The arrangement comprisescollecting means for collecting traffic measurement data and primaryprocessing means for primary processing of measurement data. Accordingto the invention the primary processing means are adapted to bedistributed and comprise first primary processing means provided in themanaging system (this may be optional) and a number of second primaryprocessing means provided in a number of managed systems. It alsocomprises processing control means for controlling at least allocationof primary processing of measurement data to a first (if provisioned) orto a second primary processing means.

The invention also suggests a managed system in a communication networkwhich comprises or communicates with collecting means adapted to collecttraffic measurement data for performance management purposes. Themanaged system comprises second primary processing means for primaryprocessing of collected traffic measurement data and processing controlmeans are provided for determining at least if/when and/or how primaryprocessing is to be performed in the second primary processing means.

The invention also provides a managing system, in a communicationsnetwork as discussed above, which is adapted to manage a number ofmanaged systems and comprises first primary processing means for primaryprocessing of collected traffic measurement data. The managing systemcomprises processing control or managing means adapted to generate orprovide and/or manage allocation handling control information and/or todistribute said allocation handling control information to second,managed, processing control means, for allocating primary processing ofmeasurement data to a first primary processing means (optional) or to asecond primary processing means provided in a managed system. In aparticular implementation it comprises a management interface fordistributing said allocation handling control information to a managedsystem.

It should be clear that the invention also covers cases when there is nofirst primary processing means in the managing system, where all primaryprocessing has been delegated to primary processing means in managedsystems.

It is an advantage of the invention that performance management isimproved and facilitated compared to known centralized systems. It isparticularly an advantage of the invention that performance managementcan be handled in an easy and flexible manner also in large networks andeven more particularly in complex networks with a large number of smallnetwork elements. It is also an advantage of the invention that anarrangement and a method for performance management are provided whichcan handle short response times of real time network managementapplications and which provide for a flexible and easy performancemanagement also when there is a huge amount of data to be collectedoften and even more particularly when different kinds of data need to becollected often and from many locations.

It is also an advantage of the invention that performance management canbe handled in an easy, flexible and straightforward manner also inmodern highly diversified networks supporting a large amount ofdifferent services and including a great variety of network nodes. Aparticular advantage of the present invention is that it allows aservice provider to operate a performance management system in a desiredmanner. It is also an advantage that performance management can beprovided for in an efficient manner without unduly loading transmissionresources within the network, i.e. that the load on the transmissionnetwork will be low even if there is a very large number of networkelements and if a large number of different types of measurements needto be done, possibly frequently.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will in the following be further explained, in anon-limiting manner, and with reference to the accompanying drawings, inwhich:

FIG. 1 is a very schematical overview of the implementation of anarrangement according to the invention,

FIG. 2 schematically illustrates an implementation of the inventiveconcept in a telecommunication network,

FIG. 3 shows a general implementation of the inventive arrangementaccording to one embodiment of the invention,

FIG. 4 is a block diagram of one particular implementation of anarrangement according to the present invention,

FIG. 5 is a block diagram showing an example in more detail of aprocessing control managing means of FIG. 4,

FIG. 6 is a block diagram describing more in detail an implementation ofa measurement control module of the aggregator module of FIG. 4,

FIG. 7 is a block diagram describing an implementation of a secondprocessing means of the aggregator module described in FIG. 4,

FIG. 8 is a sequence diagram describing the management protocol, and

FIG. 9 is a schematical flow diagram describing a procedure according tothe inventive concept.

DETAILED DESCRIPTION

In a most advantageous implementation of the present invention, as willbe exemplified with reference to the drawings below, the processingcontrol means may be adapted to allocate primary processing ofmeasurement data to a first and/or primary processing means based on oneor more policies or policy rules. This means that a flexible placementof measurement calculations in the performance management architectureis obtained with use of policy rules. According to the invention primaryprocessing or calculation is done either in the network, particularlymanaged systems or network elements, or in a managing system, forexample an OSS. It should be clear that the inventive concept alsocovers cases when all primary processing is done in a managed system,either because there is no support for primary processing in themanaging system or because the/a policy dictates that all processing isto be done in a managed system. The policy or policies, particularlypolicy rules, may comprise one or more predetermined conditions. Thepolicy rules or conditions may relate to different factors orparameters. A policy may relate to or comprise several different policyrules or conditions. In one embodiment at least some of the policy rulesor conditions relate to current parameter conditions, for examplecurrent conditions in a first processing means or in a second processingmeans or current conditions in a second processing means as compared tothe corresponding current conditions in a first processing means.Current conditions are for example current processing capacities,current sizes of managed systems where second processing means arelocated, current load, current amount of measurement data etc. Anotherexample of a condition of a policy rule is that measurements using anamount of data exceeding a given threshold value are to be processed ina second primary processing means, or vice versa measurements using anamount of data falling below a given threshold value may be processed ina first primary processing means. Another condition may relate tomeasurements based on a given number of different types of measurements,for example measurement of events, and/or incorporate other primary orpre-processed measurements. Measurements may be performed continuously,at discrete occasions or spontaneously, e.g. at occurrence of someevent.

In an exemplary embodiment, the (first and) second processing means areadapted to be controlled by policy rules relating to one or more ofnetwork size, number of managed systems (network elements), networkload, type of managed system, respective processing capacity of the(first and) second processing means, relative processing capacity of amanaged system/managing system etc. Threshold values may be given forone or more of said parameters, below or above which processing is to beperformed in a first or second processing means, as given by the rule.

Preferably at least the second primary processing means comprisecalculation means for performing aggregation calculation ofmeasurements. Alternatively also the first primary processing meanscomprise such calculation means.

Most particularly the policies or policy rules further compriseprocessing rules defining calculation or processing of measurements,i.e. how the processing or calculation is to be carried out.

Advantageously the processing control means of the arrangement comprisefirst processing control means which are adapted to generate or providesaid policies or policy rules and to distribute said policies or policyrules over a management interface to second processing control meanswhich comprises an execution engine in or communicating with saidrespective second processing means.

In an alternative implementation the first processing control means alsocomprises an execution engine. In still another embodiment the first aswell as the second processing control means comprise an executionengine. In case of a conflict, e.g. if policies are executed in thefirst processing control means and in the second processing controlmeans, a conflict may arise, e.g. about which means is handling thepolicies, the conflict is preferably (but not necessarily) handled bythe OSS. Said first processing control means may comprise a managementmodule provided in the, or a, managing system which further is adaptedto generate and manage said policies or policy rules (or conditions) andpreferably also to control generation and management of said processingrules, for example by aggregation measurement formulaes, also calledAmlets. The second processing control means are particularly located inthe respective managed systems or network elements and communicate withsaid first processing control means over the management interface.Particularly each second primary processing means and respectivecollecting means are provided in or comprise a respective aggregatormodule provided in a managed system (or network element as referred toabove). The first and second control means particularly comprisedistributed control means.

In a specific embodiment the second primary processing means of theaggregator modules comprises a respective traffic module interface forcommunication with a traffic module which comprises control planeprocessing means and user plane processing means which is adapted tocommunicate with or comprise control plane and user plane measurementcollecting means respectively. The measurement collecting meanspreferably comprises counters and/or event based counters.

The invention also suggests a managed system in a communication networkcomprising or communicating with collecting means adapted to collecttraffic measurement data for performance management purposes. Themanaged system comprises second primary processing means for primaryprocessing of collected traffic measurement data and processing controlmeans are provided for controlling or determining at least if/whenand/or how primary processing is to be performed in the second primaryprocessing means.

The invention also provides a method for performance management in acommunication network comprising a managing system and a number ofmanaged systems and which comprises means for collecting trafficmeasurement data. According to the invention the method comprises thesteps of; generating or providing allocation and/or handling controlinformation for determining if measurement data is to be handled byprimary processing in the managing system or in a managed system(handled by primary processing generally means that it ispre-processed); providing said allocation and/or handling controlinformation to managed systems supporting primary processing forexecution, and/or executing said allocation and/or handling controlinformation in a managing system; handling collected measurement datathrough primary processing in a managed system or in the managing systemas determined by the allocation and/or handling control information. Theallocation and/or handling control information particularly comprisespolicies or policy rules.

It should be clear that the above described preferred or alternativeimplementations also are applicable with respect to the managed system,the managing system and the method respectively.

Thus, according to different embodiments only the managed systems arecapable of executing e.g. policies, or only the managing system or both.In case of conflict, if both are capable of executing policies, this isadvantageously handled by OSS. Decisions are preferably made in realtime.

FIG. 1 illustrates one example of how the inventive concept can beimplemented. The arrangement for performance management here comprises amanagement module 10 which is located in managing system 100, forexample an OSS (Operations Support System), which however itself doesnot form part of the present invention. The arrangement furthercomprises an aggregator module 20A, in this particular case also anaggregator module 20B, which aggregator modules 20A, 20B are located inrespective managed systems 200A, 200B. The aggregator module 20A is incommunication with traffic module 30A₁ and the traffic module 30A₂,whereas the aggregator module 20B is in communication with a trafficmodule 30B. It should be clear that the number of traffic modules is ofno significance, any aggregator module may be connected to any number oftraffic modules, one or more. The traffic module here includes theactual measurement collection means. In this implementation it isillustrated that the aggregator module 20A, 20B are inter-connected orable to interact. This relates to an optional feature.

The management module 10 comprises means responsible for creation andmanagement of policy rules, and in preferred embodiments also so calledaggregated measurement formula which in the following are denotedAmlets. In one embodiment it supports policy execution, in anotherembodiment it does not support policy execution. The aggregator module20A, 20B is responsible for capturing performance management data(measurement data or statistics) and performing the respective requiredprocessing, for example aggregation calculations. The traffic modulehere represents a device and technology abstraction of a network elementto facilitate interaction with the performance management architecture.According to the invention a general framework is described which allowsprimary processing, aggregation calculation and processing of aggregatedmeasurements, to be pushed down into the network elements, and at leasttheoretically even out to the user equipment (not shown). The processingmeans form a network of performance management processors, and forexample calculation of aggregated measurements can be carried out in adistributed manner. In agreement with policy rules, the aggregatormodule may be responsible for capturing the measurement data orperformance management data from traffic modules and to perform, ifapplicable according to the relevant policies, an aggregationcalculation.

In particular embodiments (not shown), aggregator modules can becascaded in order to allow for hierarchical aggregation to take place,and be used to adapt the aggregation to hierarchical networks.

The various modules described as logical entities below can be mapped toa large variety of physical form factors.

Generally the invention can be seen as based on programmable networking,which is a general term concerning the capability to rapidly create,deploy and manage novel services in response to user demands, as forexample described in Campbell A et al., “A Survey of ProgrammableNetworks”, ACM SIGCOMM Computer Communications Review Vol. 29 issue 2,April 1999, by service providers or trusted third parties. Aprogrammable network offers an open API (Application ProgrammingInterface) to service programmers to facilitate service creation.Programmable networking techniques have been used for network managementas well as service creation and may include the approaches of opensignalling, active networking, “simple” mobile agents and policymanagement. Common for different programmable networking techniques arenetwork level API's which allow services/applications to be created.Generally a programmable network consists of a number of programmablenodes each exporting an API or virtual machine. Each node provides anexecution environment (EE) providing the resources and support that theapplication programs need. Basic is also a programming model to enablethe creation of services/applications. The programming model defines thetype of program entity, for example packet, policy, agent etc., theprogramming language, the division of intelligence between the node andthe program.

The present invention implements the concept of a programming model, anexecution environment and a management architecture enabling distributedcalculation of aggregation measurements in specific embodiments, moregenerally, distributed primary processing of measurement data.

According to the present invention the intelligence can be said toreside in the network nodes as a number of service components andcontrol scripts, regarded as mobile agents, which are comparativelysimple and which are downloaded to invoke the components to implement aservice. Policy rules and particularly also Amlets are here consideredas simple mobile agents that may be downloaded to managed systems ornetwork elements from a managing system, e.g. OSS.

FIG. 2 is a schematical block diagram showing an OSS 100′ (or a networkmanagement center) and a number of network elements NE1 201′, NE2 202′,NE3 203′ and NE4 204′ interconnected over a core network CN. Theperformance management arrangement according to the present inventioncomprises a management module 10′ (cf. also FIG. 3 and FIG. 4 below)provided in OSS 100′. As will be more thoroughly described in FIG. 4,the management module 10′ comprises a measurement management sub-module16′, a management interface 13′, a policy and an Amlet managementsub-module 12′ which handles management of policies and Amlets (itshould be noted that it is not limited to handle Amlets as well, inother embodiments it only handles policies). The management module 10′also comprises a measurement result storage 15′. In addition to themanagement module, particularly a policy management module, othermanagement applications, here denoted X,Y; 10 ₁′, 10 ₂′ may be provided.Operator/instructions for the creation of policies (and Amlets) areprovided to the management module 10′ over an operator interface 17′. InFIG. 2 one of the network elements, NE1 201′, is illustrated more indetail than the other network elements NE2-NE4 202′,203′,204′ which maybe constructed substantially in the same manner as NE1. NE1 201′ herecomprises a traffic module 30′ with a control plane processor CP 32 ₁′and a user plane or a traffic processor UP 31 ₁′. The network elementNE1 201′ also comprises an aggregator module 20 ₁′ as will be morethoroughly explained with reference for example to FIG. 4 below. Itshould be clear that the aggregator module does not have to be providedin the network element 201′ itself, it might also be located outside thenetwork element but in communication with the traffic module 30′provided in the network element 201′. The network element NE1 is heresupposed to be a traffic controlling network element. It should be clearthat the inventive concept is not limited to any specific networkelements, on the contrary network elements may be of many differentkinds. For example it may comprise a RBS (Radio Base Station), an RNC(Radio Network Controller), a 3G GGSN (Gateway GPRS Support Node), anSGSN (Serving GPRS Support Node), a CGSN (Combined GPRS Support Node),any router, an ATM (Asynchronous Transfer Mode) switch etc.

The control plane handles set-up and take down of communication paths,for example reserve resources etc. and when a “path” has been set-up,information thereon is provided to the aggregator module 20 ₁′.

By interaction with the policy operator over the operator interface 17′one or more policies are generated or created in the management module10′. It should be clear that this be can be very complicated, there maybe different policies for different network elements etc. However, oncethe policies and/or Amlets have been generated, they are distributedover the management interface 13′ in any appropriate manner, e.g.pushed, to the respective network elements, more particularly to theaggregator modules in or associated with the network elements, which isillustrated by the dashed-dotted arrows indicating the information flowbetween the management module and the aggregator modules. It should beclear that information also flows to the management module oncemeasurements have been done. If, according to the respective policiesapplicable for a network element, e.g. NE1 201′, processing is to bedone in the management module or OSS, (or cannot be done in NE1)measurement data is forwarded directly from the concerned traffic moduleto first primary processing means (not shown) in the management module.On the other hand, if, according to the applicable policy, measurementdata from the traffic module can be pre-processed or exposed to primaryprocessing in second primary processing or execution means of NE1(provided in the aggregator module, not shown in this fig, cf. FIG. 3,4below), the results of the primary processing are, possibly aftercaching in a measurement cache (not shown in FIG. 2), provided to themanagement module 10′.

Thus, according to the conditions of the policies provided to thenetwork elements, more particularly to the aggregator modules which arelocated externally of the network element, in a control management layerabove the traffic layer, or in the network element, it is determined ifprimary processing is to be done by the aggregator module 21′ or byprimary processing means in the management module 10′. If the conditionsfor primary processing in an aggregator module are not fulfilled,measurement data is simply provided to or pushed-up to the managementmodule without any primary processing, whereas if the applicableconditions for distributed primary processing, i.e. processing in anaggregator module, are fulfilled, the results of the primary processingare provided or pushed to the management module. A, B in the figuremerely indicate mobile communication devices connected over respectiveRAN (Radio Access Network).

FIG. 3 is a schematical block diagram describing in general terms animplementation of an arrangement according to the inventive concept. Inan OSS a management module 10′ is implemented which comprises firstprimary processing means 11 (optional) and first processing controlmeans 12 also denoted processing control managing means. In the state ofthe art systems, primary processing or pre-processing is always carriedout in the OSS, whereas here the primary processing means aredistributed and second primary processing means 21 are provided in forexample a network element NE. Second processing control means 22 herecommunicate with the first processing control means 12. Particularly thesecond processing control means 22 and the second primary processingmeans 21 are provided in an aggregator module 20′ as discussed above.The aggregator module 20′ is connected to a measurement collecting means31. Policies or policy rules and possibly, but not necessarily, alsoAmlets or similar are generated and managed in the first processingcontrol means 12 and downloaded or provided to second processing controlmeans 22, where the policies are used to determined whether the primaryprocessing is to be carried out in the second primary processing means21 or not and possibly also to determine how processing or calculationsare to be performed.

In alternative embodiments the decisions may be made in the firstprocessing control means 12 instead (or additionally). Although theinventive concept is not limited thereto, in particularly advantageousimplementations aggregated measurement formulae (Amlets) are alsohandled and distributed.

Amlets may e.g. be written in a scripting language as shown below. Theinstructions of the virtual machine defined by the language are shown inbold.

Amlet AmExample { real c1;  define M1 as {EventType1.parameterY ==value1};  define M2 as {EventType2.parameterX == EventType2.paremeterZ} define M3 as {EventType3.parameterA > value2}  subscribe(M1,M2,M3); inputEvent{   doCalc(measReceiver)->{      c1=(get(M1)+get(M2)+get(M3))/100;       send(measReceiver,calcExample,c1);    }   deactivate_rule->{      unsubscribe(M1,M2,M3);       exit( );   }  }//inputEvent }

The Amlet keyword here defines an aggregation measurement formula in thelanguage.

The define keyword enables definition of counters that are used in theAmlet. These counters are defined in terms of protocol events or asunderlying NE counters and the definition expresses the counters interms of the NE programming environment entities representing thecounters. This enables the generation of EE (Execution Environment)software (e.g. Java classes) to access the required data. The entitiesdefined by this keyword can be regarded as EE service components whichthereafter can be invoked by the actual Amlet script. Particularly thecomponents are defined in a central library or similar and imported toindividual Amlets.

The subscribe keyword instructs the underlying Amlet virtual machine(AVM) to listen for these events and it causes the AVM to subscribe tothese events in the traffic module as described above.

The inputEvent keyword defines an event handling loop to enable an Amletto respond to events in its environment.

The get keyword enables retrieval of the desired value from theunderlying counter service component.

The send keyword transfers the Amlet result to an underlyingcommunication mechanism for transfer to the next module in the chain.

The unsubscribe keyword removes subscriptions in the event the Amlet isdeactivated.

The exit keyword releases any other resources in the event the Amlet isdeactivated.

Policies are based on the same scripting language as Amlets, but they donot share all language statements. Below is shown an example of a policyrule. This particular policy rule states that if the load in the managedsystem in the NE is below a certain threshold, it is allowable toperform local evaluation of Amlets, or more generally to perform primaryprocessing in a second processing means, whereas if the load is above acertain threshold, the Amlets may not be evaluated in the NE.

Rule PolicyExample   {    const  lowLoad=30;    const  highLoad=60;   subscribe (NeLoad);    inputEvent {     NeLoad (load) -> {       get( AmState);       If ((load < lowLoad) && (AmState=off) then       send(OSS, EE_status, activateAmlet)      else if ((load >highLoad && (AmState=on) then        send (OSS,EE_status, deactiveAmlet)   }    deactivate_Rule -> {      unsubscribe(NeLoad);      exit( );   }    } // inputEvent   } // Rule

Policies are defined with the keyword Rule.

There may be many different kinds of policies or policy rules forexample in the form of conditions which also may take many differentforms. Above merely one particular example was shown.

FIG. 4 shows one implementation of an arrangement for performancemanagement according to the present invention. It comprises a managementmodule 10 ₁, particularly implemented in an OSS, an aggregator module 20₁ implemented in a network element and a traffic module 30 ₁ which is amodule abstracting the traffic machine on which measurements are made,which particularly also can be seen as implemented in a network element.This embodiment is supposed to include also so called Amlets asdiscussed above. In realistic implementations there are normally aplurality of aggregator modules in respective NEs (of which at leastsome may communicate with each other).

Aggregation measurements form part of a more comprehensive performancemanagement system. The extra functions of this management systemincluded through the aggregation measurements are not to be seen aslimiting the scope of the present invention although it relates to aparticular, advantageous embodiment. Calculation of, here, aggregatedmeasurements can also be done in the OSS, i.e. in the policy and Amletexecution means 11 ₁.

The management module 10 ₁ is, in a conventional manner, responsible forscheduling, fetching and storing of calculated results and forpost-processing of the retrieved results, which is inherent in anyperformance management system. However, according to the presentinvention the management module is here additionally responsible forcreation and deployment of Amlets. The management module 10 ₁ is heresupposed to contain, in addition to execution means 11 ₁, foursub-modules. The measurement management module 16 ₁ is responsible forscheduling, fetching and storing of calculated results andpost-processing of retrieved results which then are stored inmeasurement result storage 15 ₁. The policy and Amlet managementsub-module 12 ₁ (first processing control means) is responsible forcreation and management of policy rules and Amlets and it will be morethoroughly described below. The management module also comprises amanagement interface 13 ₁ which contains functions and protocols forenabling communication with the aggregator module 20 ₁ which for exampleis provided in a network element which comprises a number ofcommunication mechanisms needed for enabling such communication.

The aggregator module 20 ₁ also comprises, here, four sub-modules. Afirst sub-module is a management interface 23 ₁ for communication withthe management module 10 ₁ containing functions and protocols forcommunication therewith. It also comprises the traffic interface 24 ₁which provides an interface to the traffic module and allows forintegration of different NE types. The aggregator module furthercomprises a measurement control sub-module, adapted 22 ₁ to facilitatemeasure management and interaction with the measurement managementmodule 16 ₁ of the management module 10 ₁. The measurement controlmodule 22 ₁ comprises a functionality assisting in or enabling thepolicy and Amlet system to function. The aggregator module 20 ₁ furthercomprises second primary processing means or execution means, herecomprising a policy and Amlet execution engine 21 ₁ comprising thefunctions needed to enable policy rule and Amlet implementation. Thesecond processing control means referred to e.g. in FIG. 3, may e.g. beseen as included in policy and Amlet execution means 21 ₁.

The traffic module 30 ₁ comprises a number of sub-modules comprisingnetwork interfaces 33 ₁, a traffic module interface 34 ₁ enablingcommunication with the aggregator module via its traffic moduleinterface 34 ₁ and in addition thereto a control plane processor 32 ₁and a traffic user plane (or traffic) processor 31 ₁. The data plane isadapted to transfer user or application data whereas the control planecomprises protocols for managing the network traffic. Measurements canbe made in both planes. Mostly, but not exclusively, event basedcounters are mostly related to the control plane since it contains thetraffic protocols.

Some of the sub-modules will now be described, for exemplifying reasons,i.e. specific embodiments, in a more detailed manner.

A policy and Amlet management module 12 ₁ (of the management module 10 ₁of FIG. 4) is shown in FIG. 5. It comprises a policy and Amletdevelopment environment 12 ₁₁ allowing for creation and testing ofpolicies and Amlets. The development environment contains languagetranslators and libraries required to enable generation of supportingAVM (Amlet Virtual Machine) software as well as the Amlets themselves.All Amlets and supporting software is stored in an Amlet repository 12₁₃. The policy and Amlet management sub-module 12 ₁ also comprises anAmlet lifecycle management entity which is responsible for deployment ofpolicies and Amlets to network elements 12 ₁₄ and their subsequentmanagement once they have been deployed. This management function isfacilitated by cooperation with the management element in the policy andAmlet execution environment 21 ₁ in the aggregator module 20 ₁ as willbe described below. The interaction between the policy and Amletlifecycle management 12 ₁₄ and the policy and Amlet executionenvironment 21 ₁ (or in some embodiments corresponding means 11 ₁, cf.FIG. 4, in the managing systems) will be further described below. Anetwork model 12 ₁₅ is used to facilitate the deployment to the networkelements.

The measurement control sub-module 22 ₁ of the aggregator module 20 ₁may comprise a number of sub-modules or sub-parts as disclosed in FIG.6. It comprises a management proxy 22 ₁₁ abstracting the interface withthe management interface entity. Correspondingly a traffic module proxy22 ₁₄ abstracts the interface to the traffic interface entity. Themeasurement program function 22 ₁₂ is a main component of themeasurement control sub-module 22 ₁ and contains details on whichentities are being measured and how often these measurements should becompiled and output. It triggers collection of Amlet results from thepolicy and Amlet execution environment (PAEE) 21 ₁ by sending events tothe PAEE 21 ₁ to retrieve the results. It also contains informationabout which output format is to be used for each measurement program.The output formatting module 22 ₁₃ compiles the collected measurementsinto the desired output format for transmission to OSS 10 ₁. Themeasurement cache module 26 ₁ is used to store collected results priorto transmission to the management module 10 ₁.

FIG. 7 shows an exemplary implementation of a policy and Amlet executionenvironment sub-module 21 ₁ e.g. as in FIG. 4. This module is a centralcomponent of the aggregator module 20 ₁ and its primary function is toprovide a context and resources for execution of Amlets. Its maincomponent is an Amlet execution environment virtual machine (AVM orPAVM) 12 ₁₁ which provides a number of functions including implementingthe behaviour (language statements) of the Amlet programming module asdescribed above, providing a process context enabling Amlet execution,i.e. it is responsible for scheduling and dispatching Amlet jobs forexecution. It also maps Amlets onto the underlying process model. Itfurther comprises a message handling mechanism for receiving and routingmessages to Amlets, and assists in managing the Amlet lifecycle modulevia the policy and Amlet EE controller 12 ₁₁₀. In FIG. 7 the messagehandling mechanism (message queue) 12 ₁₁₃ and a number of executableentities 12 ₁₁₁ are also shown. Dashed arrows indicate dispatch of tasksand messages. The PAEE 21 ₁ further comprises Amlets/policy rules 12 ₁₆,policy and Amlet repositories 12 ₁₂,12 ₁₃, a number of event handlers 12₁₅, a number of counter handlers 12 ₁₄ and proxies for traffic moduleinterface 12 ₁₈ and management interface 12 ₁₂ respectively. In additionthereto it comprises an aggregation interface 12 ₁₉ and a managementproxy 12 ₁₇.

The functioning will be explained below. The Amlets are the actualaggregated measurements and are executed in response to incomingmessages. Messages may originate from the traffic module 30 ₁ or fromthe management module 10 ₁. All messages are serialized, i.e. placed inseries, in AVM message queue 12 ₁₁₃, so that they will be received inthe correct order by the Amlets 12 ₁₆.

A distinction is made between the handling of counters that areimplemented in the traffic module and counters implemented in the PAEE.Some counters are standardized and well known. Such counters arenormally most efficiently implemented in the traffic module directly.This applies in particular to simple counters counting the number ofoccurrences of some given event, for example the number of data packetssent on the downlink. Other counters are not standardized or they arebased on the combination of one or more parameters in the underlyingprotocol event. To calculate these counters it is necessary to processthe event data in the aggregator module, in the PAEE 21 ₁, rather thanin the traffic module. The PAEE subscribes to these events in thetraffic module and each time a subscribed protocol event occurs duringtraffic the PAEE is called. Most specifically the event handler entity(12 ₁₅) for that event is called. All event parameters are available tothe concerned event handler 12 ₁₅ which then runs through its list ofsubscribed counters and evaluates the conditions for each counter. Thecounter is then stepped.

As an example it is supposed (not shown) that counter M1 (from AmletAM1) and counter M2 (from Amlet AM2) are based on different conditionsassociated with the event E1 from a traffic protocol. When AM1 executesthe “subscribe” statement for M1, a filter is created and attached toevent handler EH1. This filter contains both the condition associatedwith the counter M1 and counter M1 itself. M1 is stepped each time thecondition is evaluated to be true. This is also true for AM2. If EH1does not exist when the AM1 subscription is invoked, then an instance ofEH1 is created.

The counters are fetched via the get( ) statement (se below) when theAmlet calculation is executed. If the counter is implemented in the PAEEvia an event handler, the counter value is fetched from the eventhandler. If on the other hand the counter exists in the traffic module,the counter value is read from there instead via a counter handlerentity which has been created earlier. This entity is able to access thecounter value via the traffic module interface.

Since both counter types are defined in the same way, the Amlet is notaware of the distinction between them and the handling of the countersis transparent to the Amlet.

The Amlets are activated on command by the measurement controller via amessage, for example doAm( ) This causes the Amlet to fetch thecounters, perform the calculation and return the value to themeasurement controller 22 ₁ (FIG. 4).

In some embodiments, a functionality corresponding to that describedabove, particularly of PAVM 12 ₁₁, is not provided in the managingsystem. In still other embodiments it is provided also in the managingsystem.

The operation of the system and the policy and Amlet lifecyclemanagement is defined by the management protocol between the policy andAmlet management sub-module 12 ₁ and the policy and Amlet executionenvironment sub-module 21 ₁. The basic interaction cycle is shown inFIG. 8 which is a sequence diagram showing the management operationsthat are used. It should be clear that the inventive concept is notlimited to the specifically indicated ordering which may be different.

Start_PAEE (1.) causes the PAEE to be activated from a passive state.This step has to be taken before any Amlets can be run. The AVM isstarted and resources are allocated. Stop_PAEE has the opposite effectand any active Amlets are deactivated (see sequence step 9 below). TheAVM is then stopped and all resources are released and the PAEE adopts apassive, listening, state.

Add_rule (2.) adds one or more Amlets or policy rules to the PAEE,including all their supporting software. Remove_rule removes all tracesof the Amlet(s) from the PAEE. Any active Amlets must first bedeactivated. Activate_rule causes a Amlet to be scheduled for execution.Memory and other resources are allocated and the Amlet is ready toreceive events. Deactive_rule (7.) causes active Amlets to be removedfrom the execution list and causes resources to be released.

The status of the EE can be read by the management module by means ofget_EE_status (4.) which can be transferred spontaneously EE_status(5.), (6.) to the management module from the aggregator module. Thisenables the management module to monitor and control the operation ofthe PAEE. The number of active rules/Amlets can be changed in accordancewith the business policy of the service provider.

In the flow diagram of FIG. 9 an overview of the main procedural stepsaccording to one embodiment of the present invention are illustrated.Here a number of policies (and possibly also Amlets) are generated orcreated and deployed in a managing system, particularly in a managementmodule of for example an OSS using policy related instructions receivedover an operator interface from an operator and taking a network modelcomprising the network elements of the network into account, 100. Whenthe policies have been deployed, they are provided (spontaneously orregularly or in any appropriate manner), in some embodimentsparticularly pushed, to the appropriate network elements, or morespecifically to aggregator modules located in or associated withrespective network elements, based on the network model, 101, i.e. thenetwork model assists in indicating which policies are to be provided towhich network elements. (Alternatively (not shown) the decisionsconcerning where the primary processing is to be done, according to theapplicable policies, are made in OSS.)

A similar procedure will take place in each network element, therefore,in the following reference is merely made to a network element denotedNEX. Measurement data is collected in NEX or via a traffic modulecontained in NEX, in a substantially conventional manner, 102. Based onthe specific policy or policies deployed in NEX, it is examined whetherthe policy conditions concerning at least if pre-processing is to bedone or can be done in NEX, are fulfilled, 103. Of course it is alsopossible to examine if the conditions are not fulfilled etc.

If the conditions are instead not fulfilled, the measurement data ispushed or provided to the management module (for example in an OSS) 103A(the arrow back to box 102 means that this is done repeatedly, accordingto a given pattern, or at occurrence of given events or spontaneously).There the measurement data will be pre-processed or handled by firstprimary processing means, 104A. If however it is established thatpre-processing may or should be performed in NEX, the pre-processing isperformed in NEX, 104, and preferably the results of the pre-processingare cached in NEX, 105. It should be clear that the general aspect ofthe inventive concept does not deal with the caching, this merelyrelating to an advantageous implementation, it might also be possible totransfer the results of the primary processing of the pre-processingdirectly to NEX; this is not intended to have a limiting effect on thescope of the invention. Then, according to any predetermined criteria,with regular time intervals, when the cache is full or according to anyother criteria, the results of the pre-processing of the measurementsare pushed to the management module or OSS, 106. (The arrow back to box102 means that measurement data collection is a repeated procedure.)Finally, although not forming part of the general scope of inventiveconcept, the results of the pre-processing can be stored in OSS orparticularly in the management module, 107.

It should be clear that the policies may be of many different kinds,that different conditions may apply or different policies may beprovided to different network elements etc. As discussed earlier in theapplication Amlets may also be handled in the same manner as thepolicies, or the policies can be seen as including also Amlets. In thatcase different Amlets may be provided to different network elements,Amlets may be provided only to some of the network elements etc. Asreferred to above the Amlets describe how the primary processing or thepre-processing is to be carried out and under what conditions etc.

According to the invention flexibility is introduced concerning thelocation for performing measurement calculations, processing in theperformance management architecture formed by the OSS and the NEs itmanages. This allows a service provider to operate his performancemanagement system to best meet the relevant objects or goals which areset. This may obviously vary from one provider to another, but one ofthe advantages is that a service provider can offload processing ofmeasurement calculations to NEs to reduce the amount of data beingtransferred from the network to the OSS. The range of measurementsoffloaded in this way can be tailored which means that not allmeasurements need to be migrated and the set of measurement migrated maybe varied at any time dependent on policy. It is also possible tooffload measurement calculations to certain NE types and not to others,depending on type of used processor etc. It is also possible to tailormeasurement processing in a network element to meet the load conditionsin the NE.

It should be clear that the invention can be varied in a number of wayswithout departing from the scope of the appended claims and it is by nomeans limited to the specifically illustrated embodiments.

1. An arrangement for performance management in a communication networkcomprising a managing system and a number of managed systems, saidarrangement comprising collecting means for collecting trafficmeasurement data and primary processing means for primary processing ofmeasurement data, wherein said primary processing means are adapted tobe distributed and comprise first primary processing means provided inthe managing system and a number of second primary processing meansprovided in or associated with a number of managed systems and whereinthe arrangement comprises processing control means for controlling atleast allocation of primary processing of measurement data to a first ora second primary processing means.
 2. An arrangement according to claim1, wherein said processing control means are adapted to allocate primaryprocessing of measurement data to a first and/or second primaryprocessing means based on one or more policies or policy rules.
 3. Anarrangement according to claim 2, wherein said one or more policies orpolicy rules comprise one or more predetermined conditions.
 4. Anarrangement according to claim 2, wherein one or more policy rules orconditions relate to current parameter conditions.
 5. An arrangementaccording to claim 3, wherein a condition states that measurements usingan amount of data falling below a given threshold value are to beprocessed in a second primary processing means, or vice versa thatmeasurements using an amount of data exceeding a given threshold valueare to be processed in the first primary processing means.
 6. Anarrangement according to claim 3, wherein a condition is thatmeasurements based on a number of different types of measurements and/ormeasurements which incorporate other primary or pre-processedmeasurements and falling below a given threshold value shall/may beprocessed in a second primary processing means.
 7. An arrangementaccording to claim 2, wherein the processing control means are adaptedto take into account conditions or policy rules relating to one or moreof network size, number of managed systems, network load, type ofmanaged system, respective processing capacity, relative processingcapacity of a managed system/managing system, and wherein thresholdvalues are given for one or more of said parameters below/above whichprocessing is to be performed in a first or a second processing means.8. An arrangement according to claim 1, wherein at least the secondprimary processing means comprise calculation means for performingaggregation calculations of measurements.
 9. An arrangement according toclaim 1, wherein said policies or policy rules further compriseprocessing rules defining calculation or processing of measurements. 10.An arrangement according to claim 1, wherein the processing controlmeans comprise first processing control means adapted to generate orprovide said policies or policy rules and to distribute said policies orpolicy rules over a management interface to second processing controlmeans comprising an execution engine in or communicating with saidrespective second processing means.
 11. An arrangement according toclaim 10, wherein said first processing control means comprises amanagement module provided in the managing system, which is adapted togenerate and manage said policies or policy rules or conditions and tocontrol generation and management of said processing rules.
 12. Anarrangement according to claim 10, wherein each second primaryprocessing means and respective collecting means are provided in orcommunicate with a respective aggregator module provided in orassociated with a managed system.
 13. An arrangement according to claim12, wherein the second primary processing means or the aggregatormodules comprise a respective traffic module interface for communicationwith a traffic module comprising control plane processing means and userplane processing means and being adapted to communicate with or comprisecontrol plane and user plane measurement collecting means respectively.14. An arrangement according to claim 13, wherein the measurementcollecting means comprises counters and/or event based counters.
 15. Amanaged system in a communication network comprising or communicatingwith collecting means adapted to collect traffic measurement data forperformance management purposes, wherein the managed system comprises oris associated with second primary processing means for primaryprocessing of collected traffic measurement data and wherein processingcontrol means are provided for determining at least if or when primaryprocessing is to be performed in the second primary processing means.16. A managed system according to claim 15, wherein the processingcontrol means comprise or implement policies or policy rules.
 17. Amanaged system according to claim 16, wherein the processing controlmeans are distributed and comprise second processing control meanscomprising an execution engine provided in or associated with themanaged system adapted to enable implementation of applicable policyrules and measurement processing, said execution engine being furtheradapted to receive policies or policy rules from an external processingcontrol management means or a first processing control means.
 18. Amanaged system according to claim 17, wherein the policies or policyrules also comprise calculation or processing rules defining rules atleast for performing aggregation calculations.
 19. A managed systemaccording to claim 15, comprising an aggregator module, said aggregatormodule comprising said execution engine and said local, secondprocessing control means, a management interface for communication witha managing system, said aggregator module further being adapted tocommunicate with a traffic module comprised in the managed systemcomprising said measurement collecting means.
 20. A managed systemaccording to claim 19, wherein the traffic module comprises a controlplane processor and a user plane processor for control plane and userplane measurements respectively.
 21. A managed system according to claim20, wherein the measurements are based on counters and/or event basedcounters.
 22. A managed system according to claim 16, wherein the policyrules comprise conditions determining whether given measurements are tobe processed in the second processing means or not, said conditionsrelating to one or more of network size, number of managed systems, loadon the second processing means, type of managed system and processingcapacity.
 23. A managing system in a communications network, adapted tomanage a number of managed systems and comprising first primaryprocessing means for primary processing of collected traffic measurementdata, wherein the managing system further comprises first processingcontrol means acting as processing control managing means adapted togenerate or provide and/or manage allocation handling controlinformation, and/or to distribute said allocation handling controlinformation to second or managed processing control means forcontrolling allocation of primary processing of measurement data to thefirst primary processing means or to a second primary processing meansprovided in a managed system, and a management interface fordistributing said allocation handling control information to saidmanaged systems.
 24. A managing system according to claim 23, whereinthe allocation and handling control information comprise policies orpolicy rules at least for handling allocation of processing ofmeasurement data.
 25. A managing system according to claim 24, whereinthe allocation and handling control information further comprisepolicies or policy rules for controlling measurement processing orcalculation.
 26. A method for performance management in a communicationnetwork comprising a managing system and a number of managed systems andfurther comprising means for collecting traffic measurement data,wherein the method comprises the steps of: generating or providingallocation and handling control information for controlling if or whenmeasurement data is to be handled by primary processing in/by themanaging system or in/by a managed system; using said allocation andhandling control information and/or distributing it to managed systemssupporting primary processing; handling collected measurement datathrough primary processing in a managed system or in the managing systemin agreement with the allocation and handling control information.
 27. Amethod according to claim 26, wherein the allocation and handlingcontrol information comprises policies or policy rules based onconditions determining if/when measurement data will or may be processedby primary processing in a managed system and/or in a managing system,and in that primary processing location related decisions are madedynamically or in real-time in a managed and/or a managing system.
 28. Amethod according to claim 27, wherein the policy rules compriseconditions with thresholds or limits above/below which primaryprocessing is to or may be handled in a managed system and/or whenprimary processing has to be handled by a managing system.
 29. A methodaccording to claim 27, wherein the allocation control and handlinginformation further comprises policies or policy rules comprisingmeasurement calculation formulae for performing aggregationcalculations.